1.2.1 テスト計画作業
TM-1.2.1 (K4)システムのテストニーズを分析して、テスト目的を達成するテスト活動およびテスト成果物を計画する。
そこでは、テスト戦略で特定された使命や目的を達成するために必要な、活動とリソースの特定を行う。 プロジェクトのガイド
計画順守の判断
目的の達成の評価に使用されるメトリクスを収集し追跡する方法
計画作業段階で 有用なメトリクスを決定することにより以下を可能にする。
ツールの選択
トレーニングのスケジュール
文書化ガイドライン の作成
テストプロジェクト用に選択された 1 つまたは複数の戦略は、計画作業段階で行うべきタスクを決定するために役立つ。 例えば
セキュリティに関して問題になりうる深刻な潜在的欠陥を多数識別した場合は、 セキュリティテストを開発して実行するために、膨大な工数を費やす。
設計仕様で深刻な欠陥が日常的に見つかることが判明した場合、テスト計画作業プロセスでは、設計仕様の静的テスト(レビュー)を追加する可能性がある。
リスク情報は、さまざまなテスト活動の優先度を決定するために使用する場合もある。
たとえば、
システム性能に関するリスクが高い場合は、コードが統合され使用可能になるとすぐに、性能テストを実行することがある。
同様に、対処的戦略を採用する場合は、探索的テストなどの動的テスト技法のテストチャータとツールを作成する計画が必要となることがある。 さらに、テスト計画段階では、
テストマネージャが以下を明確に定義する。
採用するテストレベル
各レベルの目標と目的
各レベルで使用するテスト技法などのテストに対するアプローチ
たとえば、
ある航空関連システ ムのリスクベースドテストでは、リスクアセスメントにより、必要とされるコードカバレッジのレベル、およびそのレ ベルに応じた使用すべきテスト技法を規定している。
テストベース(たとえば要求仕様やリスクなど)、テスト条件、およびそれらを満たすテストとの間には、複雑な関係がある場合がある。 これらの成果物の間には、多対多の関係があることが多い。テストの計画作業、モニタリ ング、およびコントロールを効率的に実装するには、これらの関係を理解する必要がある。また、成果物間の関係の理解に応じて、ツールを決定する場合もある。
開発チームが作成した成果物(テストベース)とテストチームが作成した成果物との間にも、関係性がある場合がある。
たとえば、
システム設計者による詳細設計仕様の要素、ビジネスアナリストによるビジネス要件、およびテストチームが 定義したテスト成果物との間の関係を、トレーサビリティマトリクスで追跡することが必要になる場合がある。 低位レベルのテストケースを設計し使用する場合、計画段階で定義した要件が存在することがある。この計画段階では、テストケースの作成が始まる前に、開発チームが作成した詳細な設計ドキュメントが承認される。
usk.icon謎。意味不明。
アジャイルライフサイクルに従う際には、テスト開始前にチーム間で情報を伝達するために、非公式な情報伝達セッショ ンを利用する場合がある。
テスト計画では、スコープの範囲外のフィーチャを明確に識別することに加えて、(リスク分析に基づき適宜)スコープに含むソフトウェアの特定のフィーチャを一覧にする場合がある。 プロジェクトに適した形式への準拠および文書化のレベルに応じて、スコープに含む各フィーチャを、対応するテスト設計仕様に関連付けることがある。
また、この段階で、テストマネージャからプロジェクトアーキテクトへの、以下をす べて揃えて提供するために
必要な作業や、コスト、納品スケジュールの把握を行うための要求事項がある場合がある。
初期のテスト環境仕様の定義
必要なリソースの可用性の検証
環境を設定する要員にその作業を割り当てていることの確認、およびテスト環境
依存関係の例としては、外部グループへのリソース要求があり、他プロジェクト(1 つのプログラム内で活動している場合)、外部のベンダーまたは開発パートナー、開発チーム、デー タベース管理者への依存などもある。